Methods and apparatuses for avoiding paging storm during ARP broadcast for ethernet type PDU

ABSTRACT

Methods and apparatuses for acquisition of an address resolution protocol (ARP)/IPv6 Neighbour cache at a user plane function (UPF) entity without performing deep packet inspection for every packet that traverses a network. The ARP broadcast/ICMPv6 Neighbour Solicitation multicast from any Ethernet client (a user equipment (UE) or clients behind the UE or clients in a data network (DN)) is responded to by the UPF entity itself, by looking up the ARP/IPv6 Neighbour cache built in the UPF entity, irrespective of whether the UPF entity acts as the core Ethernet switch or whether the core Ethernet switch is in the DN. The solution is simplified to always intercept ARP at the UPF entity and respond to it based on a local ARP/IPv6 Neighbour cache.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of International Patent Application No. PCT/CN2018/099252, filed on Aug. 7, 2018, which claims priority to Indian Patent Application No. IN201741028886, filed on Aug. 14, 2017. The disclosures of the aforementioned applications are hereby incorporated by reference in their entireties.

TECHNICAL FIELD

The present subject matter described herein, in general, relates to wireless communication networks and particularly, to avoiding paging storm during address resolution protocol broadcast in a communication network. More particularly, to methods and apparatuses for acquisition of address resolution protocol (ARP)/Internet Protocol (IP) version 6 (IPv6) Neighbour cache at the user plane function (UPF) without performing deep packet inspection for every packet traversed.

BACKGROUND

An address resolution protocol (ARP) is a protocol used by the Internet Protocol (IP) to map IP network addresses to the hardware addresses used by a data link protocol. The term address resolution refers to the process of finding an address of a computer in a network. The address is “resolved” using a protocol in which a piece of information is sent by a client process executing on the local computer to a server process executing on a remote computer. The information received by the server allows the server to uniquely identify the network system for which the address was required and therefore to provide the required address. The address resolution procedure is completed when the client receives a response from the server containing the required address.

In particular. ARP maps an IP address to a physical machine address (also known as a media access control (MAC) address) that is recognized in the local network. The protocol operates below the network layer as a part of the interface between the Open Systems Interconnection (OSI) network and OSI link layer. A table, commonly referred to as an ARP/IPv6 Neighbour cache, is used to maintain the correlation between each MAC address and its corresponding IP address. ARP provides the protocol rules for making this correlation and providing address conversion in both directions.

Thus, ARP is used by Data Link Layer to provide two basic functions: 1) Resolve IP version 4 (IPv4) addresses to MAC addresses, and 2) Maintain a Cache Table of MAC to IP addresses. To resolve Name to IP address domain name system (DNS) service is used, to resolve IP address to MAC Ethernet Address. ARP service is used.

For IPv6, the Neighbour Discovery protocol is employed, which works similar to the ARP, except that instead of sending the request as a broadcast to the entire local area network (LAN), it is sent to a link local multicast address.

Systems maintain this ARP look-up table where they store information about what IP addresses are associated with what MAC addresses. When trying to send a packet to an IP address, the system will first consult this table to see if it already knows the MAC address. If there is a value cached. ARP is not used. If the IP address is not found in the ARP table, the system will then send a broadcast packet to the network using the ARP protocol enquiring “who has 192.168.1.1”. This is sent to a special MAC address as it is a broadcast packet, thereby causing all machines on the network to receive it. Any machine with the requested IP address will reply with an ARP packet that says “I am 192.168.1.1”, and this includes the MAC address which can receive packets for that IP.

A protocol data unit (PDU) is information delivered as a unit among peer entities of networks containing control information, address information or data. In layered systems, PDU represents a unit of data specified in the protocol of a given layer that consists of protocol control information and user data. PDU is a significant term related to the initial four layers of the OSI model. In Layer 1. PDU is a bit, in Layer 2 it is a frame, in Layer 3 it is a packet and in Layer 4 it is a segment. In Layer 5 and above, PDU is referred to as data. In the context of 5^(th) Generation (5G) networks, a PDU session refers to a session established between the 5G mobile node and the network for carrying data of type IPv4 or IPv6 or Ethernet frame or any unstructured type. Hence in 5G networks, currently 3^(rd) Generation Partnership Project (3GPP) has defined three types of PDU sessions, viz., IP PDU session type, Ethernet PDU session type and Unstructured PDU session type.

3GPP is discussing the introduction of Ethernet PDU type in the 5G architecture, where a user equipment (UE) can request an Ethernet PDU type to the 5G core network and the 5G core network allocates a user plane function that acts as the PDU anchor. This anchor UPF will act as the core Ethernet switch for all the UEs that are connected to the same LAN through the Ethernet PDU. If the clients connected to the Ethernet PDU in the same LAN involve clients outside the 3GPP network (i.e., the Data Network (DN)) then in that case, an Ethernet switch in the DN may act as the core Ethernet switch for the LAN. The UPF acts as one of the leaf switches that connects the clients in the 3GPP network in this case. The UPF will tunnel the Ethernet frames received from the Ethernet PDU clients in the 3GPP network to this core Ethernet switch in the DN.

The UE can also act as an Ethernet bridge allowing clients behind UE to connect through the 3GPP network, with the UE acting as a local switch. Significantly, how the UE and/or the clients behind the UE (for bridge mode operation) obtain their Layer 3 (IP) address are out of scope of 3GPP.

In conventional wireless LAN (WLAN) networks, avoiding of ARP broadcast to all WLAN clients is handled by the WLAN Controller by building an ARP/IPv6 Neighbour cache. Here, the WLAN controller hosts the Layer 3 (L3) address management function or Dynamic Host Configuration Protocol (DHCP) server and also participates in the data plane.

It has been disclosed that wireless LAN controllers currently act as a proxy for ARP requests. Upon receiving an ARP request, the controller responds with an ARP response instead of broadcast the request to every WLAN client. This scenario has two advantages, viz., the upstream device that sends out the ARP request to the client will not know where the client is located, and power for battery-operated devices such as mobile phones and printers is preserved because they do not have to respond to every ARP requests.

Reference is made to Dynamic Host Configuration Protocol (DHCP) Snooping (Through Deep Packet Inspection) And Building ARP/IPv6 Neighbour Cache, wherein it has been disclosed that DHCP snooping allows a Catalyst switch to inspect DHCP traffic traversing a layer two segment and track which IP addresses have been assigned to hosts on which switch ports. This information can be handy for general troubleshooting, but designed specifically to aid two other features, viz., IP source guard and dynamic ARP inspection. These features help to mitigate IP address spoofing at the layer two access edge.

Notably, snooping L3 address assignment (like DHCP snooping) and replying to ARP request directly from switch are already existing art in wired LAN and wireless LAN.

The communication network can be a 4^(th) Generation (4G) Long-Term Evolution LTE or a 5G network. However, what is unique to cellular 5G based Ethernet PDU sessions and the Ethernet LAN network is that a cellular network may have millions of subscribers and many of them may be in Connection Management-idle (CM-IDLE) state at a time. Doing DHCP snooping at an anchor switch (say a UPF entity) for so many subscriber sessions through per packet inspection is computationally intensive and it hogs the computing resources of the switch from spending cycles on normal packet forwarding. Also for the case of core Ethernet switch being in the DN and the L3 Address Management server (DHCP) located in the DN, the DHCP traffic for the clients in the DN will not traverse the UPF. Hence, the UPF cannot snoop the DHCP packets in such cases.

Further, the state of art technologies is yet to discuss or solve the following problem in 3GPP, wherein after the UE and/or the clients behind the UE somehow get their Layer 3 address (IP address), UEs perform an ARP request or Neighbour Discovery Protocol request to discover the Ethernet MAC address of other UE/clients in the same LAN and this ARP request/Neighbour Discovery Protocol (NDP) request is tunnelled by the radio access network (RAN) to the core network user plane function (UPF) entity. Thereafter, two scenario possibilities exist.

Scenario 1:

If a UPF entity acts as the Ethernet switch, it will broadcast the ARP or multicast the NDP to every UE/client in the LAN, as illustrated in FIG. 1. Since the UEs are connected to the communication network through a tunnel, such broadcast/multicast will result in separate ARP/NDP message being sent on each tunnel.

Scenario 2:

If a data network (DN) behind a UPF entity acts as the Ethernet switch, the UPF entity will forward the ARP or the NDP request from the UE or the clients behind the UE to the DN and the core Ethernet switch will then send back the ARP request on a Layer 2 (L2) broadcast address or the NDP Neighbour Solicitation request on a link local multicast address which will result in the UPF entity sending the ARP or the Neighbour Solicitation Request to every UE in the LAN, as illustrated in FIG. 2.

This results in a massive paging storm in the network if many UEs are in CM-IDLE state. Similar problems also occur when clients behind the data network name (DNN) also becomes a part of the LAN and issues ARP/NDP (Neighbour Discovery Protocol) Neighbour Solicitation. Significantly, paging or location finding is the process by which the network initiates a query for an endpoint's location. It is implemented by sending beacons (a broadcast message) to all cells such that one of the cells could locate the user (IP address). A UE in CM-IDLE state is registered with the network but has no signalling connection established. Further, how the UE obtains its MAC address and upper layer address (IP) is also out of scope of 3GPP.

Thus, there is a need to build ARP cache/IPv6 Neighbour Cache at the UPF entity without performing deep packet inspection for every packet traversed in order to snoop into DHCP requests, such that the ARP cache/IPv6 Neighbour Cache can be used for avoiding paging storm during when an ARP request or a Neighbour Solicitation Request is issued in 5G networks for the Ethernet PDUs, to do away with unnecessary occupation and wastage of network resources.

Significantly, responding to ARP from a local ARP/IPv6 Neighbour cache in a switch instead of broadcasting to every node in the LAN is a well-known mechanism. Accordingly, the objective technical problem solved by the present disclosure is avoiding paging storm during ARP broadcast/NDP multicast in 5G networks by building an ARP cache/IPv6 Neighbour Cache in the UPF entity itself.

The above-described need for avoiding paging storms during ARP broadcast/NDP multicast in 5G networks is merely intended to provide an overview of some of the problems of conventional systems/mechanism/techniques, and are not intended to be exhaustive. Other problems with conventional systems/mechanism/techniques and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.

SUMMARY

This summary is provided to introduce concepts related to methods for avoiding paging storm during ARP broadcast/NDP multicast for Ethernet type PDU in 5G networks and the same are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining or limiting the scope of the claimed subject matter.

An object of the present disclosure is to build an ARP cache/IPv6 Neighbour cache in a UPF entity without doing deep packet inspection for every packet traversed such that the ARP cache/IPv6 Neighbour Cache can be used to avoid ARP broadcast/NDP multicast.

Another object of the present disclosure is to provide a mechanism for a Session management function (SMF) entity to learn which tunnel in a UPF entity is destined towards which MAC address(es).

Another object of the present disclosure is to update the ARP/IPv6 Neighbour cache present in the UPF entity.

Another object of the present disclosure is updating the ARP/IPv6 Neighbour cache in a UPF entity by a DN.

Yet another object of the present disclosure is to solve the technical problems recited hereinabove by providing an anchor UPF entity that acts as a core Ethernet switch when L3 address management function is at the SMF entity or at the DN.

Yet another object of the present disclosure is to solve the technical problems recited hereinabove by providing a DN that acts as a core Ethernet switch when L3 address management function is at the SMF entity or at the DN.

Yet another object of the present disclosure is to provide Deep Packet Inspection (DPI) at a UPF entity acting as a core Ethernet switch.

Yet another object of the present disclosure is to provide Deep Packet Inspection (DPI) at a DN acting as a core Ethernet switch.

Yet another object of the present disclosure is to provide Gratuitous Attribute Registration Protocol (GARP) or Internet Control Message Protocol version 6 (ICMPv6) Neighbour Advertisement from the UE to update the Ethernet switch ARP cache/IPv6 Neighbour Cache.

Yet another object of the present disclosure is to avoid paging storm during ARP broadcast/NDP multicast for Ethernet type PDU.

In accordance with the first aspect of the present disclosure, there is provided a method of acquisition of layer-2 (L2) addresses seen in a tunnel for an end user device at a user plane function (UPF) entity. The method comprises: receiving, by the UPF entity, a request from a session management function (SMF) entity for notifying any source L2 address detected on said tunnel by the UPF entity; detecting, by the UPF entity, an L2 packet with a new source L2 address on said tunnel; and sending, by the UPF entity, the new source L2 address detected on said tunnel to the SMF entity. The tunnel between the UPF entity and the network terminating the end user device is set up by a user plane setup message initiated by a session management function (SMF) entity towards the UPF entity and associated with Ethernet type protocol data unit (PDU) sessions. Further, the tunnel setup at the UPF entity is towards an Access Network (AN) or a Data Network (DN).

In one implementation of the first aspect, the present disclosure provides a method for the SMF entity to learn which tunnel in the UPF entity is destined towards which MAC address(es).

In accordance with the second aspect of the present disclosure, there is provided a method for updating an address resolution protocol (ARP) cache/IPv6 Neighbour Cache in a user plane function (UPF) entity by a session management function (SMF) entity. The method comprises: sending, by the SMF entity, a first request message to the UPF entity to update the ARP cache/IPv6 Neighbour Cache, wherein the first request message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map; updating, by the UPF entity, the ARP cache/IPv6 Neighbour Cache with the L2 address map; and sending, by the UPF entity, a first response update message after updating the ARP cache/IPv6 Neighbour cache to the SMF entity.

In one implementation of the second aspect, the present disclosure provides a method of updating the ARP cache/IPv6 Neighbour cache built in a UPF entity. The SMF entity issues an N4 UPF Configuration Update Request to the UPF entity and carries the update ARP/IPv6 Neighbour cache command along with the L3 address to L2 address map. The UPF entity updates the ARP/IPv6 Neighbour cache with the provided map and sends a user plane UPF Configuration Update Response.

In accordance with the third aspect of the present disclosure, there is provided a method for updating an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity by an L3 address management function of a data network (DN). The method comprises: sending, by the DN, a first update message to a network element function (NEF) entity, wherein said first update message comprises an L2 address and an L3 address map; determining, by the NEF entity, a local configuration that indicates which session management function is controlling the UPF entity; and sending, by the NEF entity, the first update message to at least one session management function.

In one implementation of the third aspect, the present disclosure provides a method for updating the ARP/IPv6 Neighbour cache built in the UPF entity by the DN. When the L3 address management function is at the DN, this method is employed by the DN to inform the SMF entity about the L2 address to L3 address map such that SMF entity can update the ARP/IPv6 Neighbour cache in the UPF entity.

In accordance with the fourth aspect of the present disclosure, there is provided a method for performing L3 address management function in a session management function (SMF) entity to update an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity, wherein said UPF entity is a core Ethernet switch. The method comprises: receiving, by the UPF entity, a first request message comprising a first request message over layer-2 (L2), said message comprising source media access control of the end user device, from an end user device; forwarding, by the UPF entity, the first request message to the SMF entity; sending, by the SMF entity, a first response message to the UPF entity; forwarding, by the UPF entity, the first response message to the end user device; sending, by the SMF entity, a first request update message to the UPF entity to update the ARP/IPv6 Neighbour cache, wherein the first request update message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map; updating, by the UPF entity, the ARP/IPv6 Neighbour cache with the L2 address map; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In one implementation of the fourth aspect, the present disclosure provides an L3 address management function for Ethernet PDU sessions and for the clients behind the UE/DN in the LAN, where the L3 address management function is located at the SMF entity. The L3 address management function may be a DHCP server or an IPv6 Address assignment function.

In accordance with the fifth aspect of the present disclosure, there is provided a method for performing layer-3 (L3) address management function in a session management function (SMF) entity to update an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity, wherein a data network (DN) is a core Ethernet switch. The method comprises: receiving, by the core Ethernet switch, from the end user device, a first request message comprising a first request message over layer-2 (L2), said message comprising source media access control of the end user device; forwarding, by the core Ethernet switch, the first request message to the SMF entity; sending, by the SMF entity, a first response message to the core Ethernet switch for providing L3 address allocation, wherein the first response message comprises the L3 address allocation forwarded by the SMF; forwarding, by the core Ethernet switch, the first response message to the end user device; acquiring, by the SMF entity, the L2 addresses for the end user device at UPF entity as indicated in the first aspect of the present disclosure; sending, by the SMF entity, a first request update message to the UPF to update the ARP/IPv6 Neighbour cache, wherein the first request update message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map; updating, by the UPF entity, the ARP/IPv6 Neighbour cache with the L2 address map; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In one implementation of the fifth aspect, the present disclosure provides a method for updating the ARP/IPv6 neighbour cache at the UPF entity when an L3 address is assigned by the DN.

In accordance with the sixth aspect of the present disclosure, there is provided a method for updating an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity when a layer-3 (L3) address is assigned by a data Network (DN), wherein said UPF entity is a core Ethernet switch. The method comprises: requesting, by a session management function (SMF) entity, for notifying any source layer-2 (L2) address detected by the UPF entity, wherein the L2 address is detected by the UPF entity on a tunnel for a UE at the UPF entity or on a tunnel for clients in the DN; detecting, by the UPF entity, an L2 packet with new source L2 address on said tunnel; sending, by the UPF entity, the new source L2 address detected on said tunnel to the SMF entity; sending, by the DN, a first update message comprising an L2 address and an L3 address map to the SMF entity; forwarding, by the SMF entity, the first update message comprising an L2 address and an L3 address map to the UPF entity to update the ARP/IPv6 Neighbour cache; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In one implementation of the sixth aspect, the present disclosure provides a method for updating the ARP/IPv6 neighbour cache at the UPF entity when an L3 address is assigned by the DN.

In accordance with the seventh aspect of the present disclosure, there is provided a method for performing gratuitous address resolution protocol (GARP)/ICMPv6 Neighbour Advertisement to update the Ethernet switch ARP/IPv6 Neighbour cache. The method comprises: initiating, by an application layer, a device trigger message request to initiate GARP/ICMPv6 Neighbour Advertisement for a 3GPP user equipment (UE) through a network element function (NEF) entity, wherein the device trigger request message comprises an external identifier (ID) to denote a user equipment (UE); forwarding, by the NEF entity, the device trigger request message to an access management function (AMF) entity if the external ID belongs to a valid UE; forwarding, by the AMF entity, the device trigger request message to an end user device; sending, by the end user device, a device trigger response message to the AMF entity; forwarding, by the AMF entity, the device trigger response message to the NEF entity; forwarding, by the NEF entity, the device trigger response message to the application layer, and initiating, by the user equipment upon receiving the device trigger message, a GARP/ICMPv6 Neighbour Advertisement message.

In one implementation of the seventh aspect, the present disclosure provides a method for performing gratuitous address resolution protocol (GARP)/ICMPv6 Neighbour Advertisement to update the Ethernet switch ARP/IPv6 Neighbour cache. The UE/client behind UE/clients in DN, after learning the layer 3 address, does a gratuitous ARP/ICMPv6 Neighbour Advertisement to update the Ethernet switch (which can be UPF entity or the DN behind UPF entity) ARP/IPv6 Neighbour cache. Through this the switch learns the ARP/IPv6 Neighbour cache, where the UE can be triggered by the device trigger message mentioned above to initiate the GARP/IPv6 Neighbour Advertisement for itself or for the clients behind it, while the clients in the DN are triggered by some application means outside the scope of 3GPP.

In accordance with the eighth aspect of the present disclosure, there is provided a network element for acquiring layer-2 (L2) addresses seen in a tunnel for an end user device. The network element comprises: a processor unit configured to detect an L2 packet with new source L2 address on said tunnel; a transceiver module configured to receive a request for notifying any source L2 address detected on said tunnel, and further configured to send the new source L2 address detected on said tunnel; and a memory unit operatively coupled to the processor unit and transceiver module. The tunnel between the network element and a network terminating the end user device is set up by a user plane setup message initiated by a session management function (SMF) entity towards the network element and associated with Ethernet type protocol data unit (PDU) sessions. Further, the tunnel setup at the network element is towards an Access Network (AN) or a Data Network (DN).

In accordance with the ninth aspect of the present disclosure, there is provided a network function entity for updating an address resolution protocol (ARP)/IPv6 Neighbour cache in a network apparatus by an L3 address management function. The network function entity comprises: a processing unit configured to determine a local configuration that indicates which session management function (SMF) is controlling the network apparatus; a transceiver module configured to receive a first update message, wherein said first update message comprises an L2 address and an L3 address map. The transceiver module is further configured to send the first update message to at least one SMF.

In contrast to the available technology in other approaches, the subject disclosure avoids paging storm during ARP broadcast/NDP multicast in 5G networks that unnecessarily occupied and hogged the network resources. The subject disclosure suggests building an ARP/IPv6 neighbour cache at the UPF entity without performing deep packet inspection for every packet traversed.

The various options and preferred embodiments referred to above in relation to the first implementation are also applicable in relation to the other implementations.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

FIG. 1 illustrates a network deployment scenario where a UPF entity acts as the Ethernet switch and broadcasts the ARP/multicasts the ICMPv6 Neighbour Solicitation to every UE in the LAN, in accordance with one embodiment of a problem of the present subject matter.

FIG. 2 illustrates a network deployment scenario where a DNN acts as the Ethernet switch and broadcasts the ARP/multicasts the ICMPv6 Neighbour Solicitation to every UE in the LAN, in accordance with another embodiment of a problem of the present subject matter.

FIG. 3 illustrates a procedure for SMF entity to build MAC address to N4 session map, in accordance with an embodiment of the present subject matter.

FIG. 4 illustrates an ARP/IPv6 Neighbour cache update procedure, in accordance with another embodiment of the present subject matter.

FIG. 5 illustrates updating MAC, L3 address map from DN to UPF entity via NEF, SMF entity, in accordance with another embodiment of the present subject matter.

FIG. 6 illustrates L3 address management function in SMF entity and update of ARP/IPv6 Neighbour cache in UPF entity when UPF entity is the core Ethernet switch, in accordance with another embodiment of the present subject matter.

FIG. 7 illustrates an L3 address management function in DN and update of ARP/IPv6 Neighbour Cache in UPF entity when a core Ethernet switch is in the DN, in accordance with another embodiment of the present subject matter.

FIG. 8 illustrates deep packet inspection at UPF entity and building an ARP/IPv6 Neighbour cache when UPF entity is the core Ethernet switch, in accordance with another embodiment of the present subject matter.

FIG. 9 illustrates a core switch in a DN and a UPF entity acting as a tunnelling node to the DN, in accordance with another embodiment of the present subject matter.

FIG. 10 illustrates a UE that performs gratuitous ARP or ICMPv6 neighbour Advertisement to update the ARP/IPv6 Neighbour cache, in accordance with another embodiment of the present subject matter.

FIG. 11 illustrates a network apparatus in accordance with another embodiment of the present subject matter.

FIG. 12 illustrates a network function entity in accordance with another embodiment of the present subject matter.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the disclosure and may not be to scale.

DETAILED DESCRIPTION OF THE DISCLOSURE

The disclosure can be implemented in numerous ways, as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the disclosure may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the disclosure.

A detailed description of one or more embodiments of the disclosure is provided below along with accompanying figures that illustrate the principles of the disclosure. The disclosure is described in connection with such embodiments, but the disclosure is not limited to any embodiment. The scope of the disclosure is limited only by the claims and the disclosure encompasses numerous alternatives, modifications, and equivalents. Numerous details are set forth in the following description in order to provide a thorough understanding of the disclosure. These details are provided for the purpose of example and the disclosure may be practiced according to the claims without some or all of these details. For the purpose of clarity, technical material that is known in the technical fields related to the disclosure has not been described in detail such that the disclosure is not unnecessarily obscured.

In the following detailed description, numerous details are set forth in order to provide a thorough understanding of the disclosure. However, it will be understood by those skilled in the art that the present disclosure may be practiced without these details. In other instances, well-known methods, procedures, and components, modules, units and/or circuits have not been described in detail to not obscure the disclosure.

Although embodiments of the disclosure are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium that may store instructions to perform operations and/or processes.

Although embodiments of the disclosure are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

The subject disclosure lies in building an ARP/IPv6 Neighbour cache at a UPF entity without performing deep packet inspection for every packet traversed such that the ARP/IPv6 Neighbour cache can be used to avoid paging storm during ARP broadcast/ICMPv6 Neighbour Solicitation multicast for Ethernet type PDU in 5G networks.

In the present disclosure, methods for building ARP/IPv6 Neighbour cache at a UPF entity are disclosed.

While aspects are described for methods for building an address resolution protocol (ARP)/IPv6 Neighbour cache at a user plane function (UPF) entity without performing deep packet inspection for every packet that traverses the network has been disclosed, the present disclosure may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, devices/nodes/apparatus, and methods.

Henceforth, embodiments of the present disclosure are explained with the help of exemplary diagrams and one or more examples. However, such exemplary diagrams and examples are provided for the illustration purpose for better understanding of the present disclosure and should not be construed as limitation on scope of the present disclosure.

In Ethernets, Ethernet addresses or MAC addresses are required for communication between network devices. Such devices send or receive packets to Ethernet addresses that consists of 48 bits or 6 octets, while IPv4 addresses consists of 32 bits or 4 octets and IPv6 addresses consist of 128 bits or 16 octets. ARP deals with the two kinds of packets: ARP request and ARP reply. When a sender wants to know the MAC address of the destination IP node, it broadcasts the ARP request to every host in the network. The destination node sends a reply to the sender with MAC address through ARP reply in a unicast mode. Similarly, for IPv6 case Neighbour discovery deals with two kinds of packets. An ICMPv6 Neighbour Solicitation, which is sent as a multicast to all the devices attached to the link layer multicast network, and a ICMPv6 Neighbour Advertisement, which is sent as a unicast reply to the device that initiated the ICMPv6 Neighbour Solicitation.

Association between the UE and a Data Network that provides a PDU connectivity service. The type of association can be IP, Ethernet, or unstructured. 3GPP is discussing the introduction of Ethernet PDU type in the 5G architecture such that the UE can request an Ethernet PDU type to the 5G core network.

For a PDU session set up with the Ethernet PDU session type, the Session management function (SMF) entity and the UPF entity acting as PDU session anchor can support specific behaviours related with the fact the PDU session carries Ethernet frames. Neither a MAC nor an IP address is allocated by the 5G core network (5GC) to the UE for this PDU session.

The SMF entity is a network element, or a logic module in a network element that performs session establishment, modification and release, including tunnel maintenance between UPF entity and AN node, UE IP address allocation and management selection and control of UP function, support for interaction with external DN for transport of signalling for PDU session authorization/authentication by external DN and the like. The SMF entity performs IP address management procedure based on the selected PDU type. If IPv4 PDU type is selected, an IPv4 address is allocated to the UE. Similarly, if IPv6 PDU type is selected, an IPv6 prefix is allocated.

The UPF entity is a network element, or a logic module in a network element that handles the user plane path of PDU sessions. A UPF entity that provides the interface to a Data Network supports the functionality of a PDU session anchor. Traffic detection and routing information sent by the SMF entity to the UPF entity for a PDU session is associated with Network instance for detection and routing of traffic. A UPF entity can be controlled by a single SMF or by multiple SMFs, for different PDU sessions. The UPF entities traffic detection capabilities are used by an SMF entity to control traffic reporting, quality of service (QoS) enforcement, and traffic routing.

Introducing Ethernet PDU type in the 5G architecture allows a UE to request an Ethernet PDU type to the 5G core network, and the 5G core network allocates a user plane function that acts as the PDU anchor. This anchor UPF entity will act as the core Ethernet switch for all the UEs that are connected to the same LAN through the Ethernet PDU. The UE can also act as an Ethernet bridge allowing clients behind UE to connect through the 3GPP network, with the UE acting as a local switch.

As per current agreement as captured in the latest draft of 3GPP Technical Specification (TS) 23.501 clause 5.6.10.2, for the Ethernet PDU, the SMF entity is not involved in any address allocation. How the UE obtains its MAC address and upper layer address (IP) is out of scope of 3GPP as how the UE and/or the clients behind the UE (for bridge mode operation) obtain their layer 3 (IP) address is also out of scope of 3GPP.

The principle behind the present disclosure is for the ARP broadcast/ICMPv6 Neighbour Solicitation multicast from any Ethernet client (UE or clients behind UE or clients in DN) to be responded by a UPF entity itself, by looking up the ARP/IPv6 Neighbour cache built in the UPF entity, irrespective of whether the UPF entity acts as the core Ethernet switch or the core Ethernet switch is in the DN. The solution is simplified to always intercept ARP/ICMPv6 Neighbour Solicitation at the UPF entity and respond to it based on a local ARP/IPv6 Neighbour cache.

Notably, responding to ARP/ICMPv6 Neighbour Solicitation from a local ARP/IPv6 Neighbour cache in a switch instead of broadcasting/multicasting to every node in the LAN is a well-known mechanism as indicated hereinabove. Therefore, the present disclosure focuses on how to build an ARP/IPv6 Neighbour cache in the UPF entity itself.

The Ethernet clients who are end users such as UEs/clients behind the UE/clients in DN perform an ARP/ICMPv6 Neighbour Solicitation request to discover the Ethernet MAC address of other UE/clients behind the UE/clients in DN in the same LAN where this ARP/ICMPv6 Neighbour Solicitation request is tunnelled by the RAN to the core network UPF entity, thereafter, two possibilities exist. The first scenario, as illustrated in FIG. 1, is that if a UPF entity acts as the Ethernet switch, it will broadcast the ARP/Neighbour Solicitation to every UE in the LAN. The second scenario, as illustrated in FIG. 2, is that if a DN behind UPF entity acts as the Ethernet switch, the UPF entity will forward the ARP/ICMPv6 Neighbour Solicitation to the DN, and the DN will then send back the ARP broadcast on an L2 broadcast address/will multicast ICMPv6 Neighbour Solicitation on an L2 multicast address which will result in the UPF entity sending the ARP/ICMPv6 Neighbour Solicitation to every UE in the LAN. Significantly, each of these scenarios results in a massive paging storm in the network if many UEs are in CM-IDLE state. A similar problem also exists when clients behind the DNN also become part of the LAN and issue ARP/ICMPv6 Neighbour Solicitation. Notably, the illustrations in FIGS. 1 and 2 have been provided with respect to ARP while these issues are also applicable for IPv6 Neighbour Discovery when ICMPv6 Neighbour Solicitation is in multicast. Separate illustrations are not provided for IPv6 Neighbour Discovery and a person skilled in the art would understand the illustrations in the context of both ARP and IPv6 Neighbour Discovery.

To solve the problem of paging storm that occurs during ARP broadcast/ICMPv6 Neighbour Solicitation multicast for Ethernet type PDU in 5G networks (which till now has not been discussed or solved in 3GPP), in a first implementation, the present disclosure provides a method of acquisition of layer-2 (L2) addresses seen in a tunnel for an end user device at a user plane function (UPF) entity. The method comprises: receiving, by the UPF entity, a request from a session management function (SMF) entity for notifying any source L2 address detected on said tunnel by the UPF entity; detecting, by the UPF entity, an L2 packet with new source L2 address on said tunnel; and sending, by the UPF entity, the new source L2 address detected on said tunnel to the SMF entity. The tunnel between the UPF entity and the network terminating the end user device is set up by a user plane setup message initiated by a session management function (SMF) entity towards the UPF entity and associated with Ethernet type protocol data unit (PDU) sessions. Additionally, the tunnel setup at the UPF entity is towards an Access Network (AN) or a Data Network (DN).

In this implementation, the present disclosure provides a method for the SMF entity to learn which tunnel in the UPF entity is destined towards which MAC address(es).

Entities on the LAN connected to the communications system, for example, 5G System (5GS) by the UE may be allocated an IP address by the DN, but this is not defined. Accordingly, it is clear that the SMF entity is not aware of which tunnel (can be an N3 tunnel or a tunnel towards DN) in a UPF entity is used for routing traffic towards which MAC address(es). The SMF entity needs to have this knowledge especially for the case where the L3 address management function for Ethernet PDU sessions is not with the SMF entity (i.e., the DHCP/IPv6 Router is not co-located with the SMF entity).

FIG. 3 illustrates a procedure for an SMF entity to build a MAC address to N4 session mapping, in accordance with a first embodiment of the present subject matter for the end to end solution for building the ARP/IPv6 Neighbour cache at the UPF entity. After the SMF entity sets up the N4 session and has informed the UPF entity about the tunnel to be created (N3 tunnel or a tunnel towards DN), the SMF entity sends an N4 message to subscribe to the UPF entity for notifying the SMF entity whenever a new source MAC address is seen on the tunnel created at the UPF entity. Such subscriptions shall be done for the N4 sessions associated with Ethernet type PDU sessions.

Notably, the N4 session is akin to a tunnel setup for a PDU session between an Access Network and a UPF entity or between the UPF entity and a DN, by the SMF entity using the N4 Setup request message. Thus, the “tunnel” is between the UPF entity and the AN or between the UPF entity and the DN. What is done by SMF entity is a signalling message (N4 setup request) to set up this tunnel.

In particular, a session is set up between the SMF and the UPF entities for each PDU session or for each tunnel towards the DN. Using these session parameters related to that PDU session are exchanged between the SMF and UPF entities. For example, in order for the SMF entity to learn which MAC address are seen on a PDU session tunnel/tunnel towards DN, the information about the MAC address seen has to be carried over this session from the UPF entity to the SMF entity.

Thus, the SMF entity may subscribe for this notification only if the L3 address management function for Ethernet PDU sessions is outside the SMF entity (i.e., in the DN). When the UPF entity sees an L2 packet on the tunnel with a new MAC address, the UPF entity notifies the SMF entity immediately about the new MAC address seen for that N4 session.

An advantage of this method is that as part of updating ARP/IPv6 Neighbour cache in a UPF entity by the DN, if the NEF entity does not have the configuration of which UPF entity is controlled by which SMF entity(ies), it will end up forwarding the <L3 address, MAC address>. UPF address map to all SMF entities. Thus, the SMF entity that got notified of the source MAC from a UPF entity would be the only SMF entity that can update the UPF entity.

Further advantage of this method being that as part of updating an ARP/IPv6 Neighbour cache in a UPF entity by the DN, if the core Ethernet switch is in the DN and the UPF entity is not acting as the core Ethernet switch, then the L3 address management function cannot get the UPF entity address through the DHCP/IPv6 stateless address auto-configuration (SLAAC) request is received. Also, if the client sending the L3 address discovery request is in the DN (and not a UE or a client behind the UE), the request will not come through the UPF entity at all. In such a case, the L3 address management function cannot provide any UPF entity address to the SMF entity. Thus, one way the SMF entity can find out which UPF entity to update the ARP/IPv6 Neighbour cache is by employing the first implementation of the present disclosure.

In a second implementation, the present disclosure provides a method for updating an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity by a session management function (SMF) entity. The method comprises: sending, by the SMF entity, a first request message to the UPF entity to update the ARP/IPv6 Neighbour cache, wherein the first request message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map; updating, by the UPF entity, the ARP/IPv6 Neighbour cache with the L2 address map; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In this implementation, the present disclosure provides a method of updating the ARP/IPv6 Neighbour cache built in a UPF entity. The SMF entity issues an N4 UPF Configuration Update Request to the UPF entity and carries the update ARP/IPv6 Neighbour cache command along with the L3 address to L2 address map. The UPF updates the ARP/IPv6 Neighbour cache with the provided map and sends an N4 UPF Configuration Update Response.

FIG. 4 illustrates how the ARP/IPv6 Neighbour cache is updated in a UPF entity by the SMF entity in accordance with second embodiment of the present subject matter. The SMF entity issues an N4 UPF Configuration Update Request to the UPF entity and carries the Update ARP/IPv6 Neighbour Cache command along with the L3 address to L2 address map. The UPF entity updates the ARP/I IPv6 Neighbour cache with the provided map and sends an N4 UPF Configuration Update Response.

In a third implementation, the present disclosure provides a method for updating an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity by an L3 address management function of a data network (DN). The method comprises: sending, by the DN, a first update message to a network element function (NEF) entity, wherein said first update message comprises an L2 address and an L3 address map; determining, by the NEF entity, a local configuration that indicates which session management function is controlling the UPF entity; and sending, by the NEF entity, the first update message to at least one session management function entity.

In this method, before sending the first update message to a NEF entity, the method performs the steps of: sending, by the UPF entity, a first request message comprising a Dynamic Host Configuration Protocol (DHCP) Request or an Internet Protocol version 6 (IPv6) Router Solicitation to the L3 address management function in the DN; allocating, by the L3 address management function, an L3 address; and sending, by the DN, a first response message comprising L3 address allocation command to the UPF entity. The first update message optionally comprises a second identifier of the UPF entity from which the L3 address discovery request was received. The NEF entity forwards the first update message to all the SMF entities in a network, if no local configuration is available or if the identifier of the UPF entity was not received in the first update message. The L3 address allocation command comprises a DHCP Request or an IPv6 Router Solicitation.

In this implementation, the present disclosure provides a method for updating the ARP/IPv6 Neighbour cache built in the UPF entity by the DN. When the L3 address management function is at the DN, this method is employed by the DN to inform the SMF entity about the L2 address to L3 address map such that SMF entity can update the ARP/IPv6 Neighbour cache in the UPF entity.

FIG. 5 illustrates updating MAC, L3 address map from DN to UPF entity via NEF entity. SMF entity, in accordance with a third embodiment of the present subject matter. When updating an ARP/IPv6 Neighbour cache in a UPF entity by a DN, if the L3 address management function is at the DN, then a procedure is needed for the DN to inform the SMF entity about the L2 address to L3 address map such that SMF entity can update the ARP/IPv6 Neighbour cache in the UPF entity.

Once the L3 address management function in the DN receives an L3 address assignment request from a client, tunnelled by a UPF entity, the L3 address management function in the DN acts as an application and updates the NEF entity with the following details.

1. A request to update <MAC address, L3 address mapping> along with the identifier of the UPF entity from which the L3 address discovery request was received, if available. This implies that the UPF entity identifier is optional. It may not be available to the L3 address management function in the DN, in certain cases when the core Ethernet switch is in the DN.

2. If the NEF entity has a local configuration of which SMF entity(ies) are controlling the UPF entity, the NEF entity forwards this update request to only those SMF entity(ies). Otherwise, it sends this update request to all SMF entity(ies).

3. If the UPF entity identifier is received from NEF entity to SMF entity, then the SMF entity can directly update the ARP/IPv6 Neighbour cache on that UPF entity by employing the second implementation of the present disclosure.

4. If no UPF entity identifier is received from NEF entity to SMF entity, only the SMF entity(ies) that already learned which UPF entity has seen that MAC address before (through the notification defined when SMF entity is learning which tunnel in UPF entity is destined towards which MAC address) will forward the ARP/IPv6 Neighbour cache update request to the respective UPF(s) as defined while updating the ARP/IPv6 Neighbour cache in UPF entity.

When an L3 address management function is at the SMF entity, the L3 address management function for Ethernet PDU sessions and for the clients behind the UE/DN in the LAN is located at the SMF entity itself. The L3 address management function may be a DHCP server or an IPv6 SLAAC management function. In such a scenario, there are 2 cases to consider.

Case 1:

The UPF entity is the core Ethernet switch.

Case 2:

The core Ethernet switch is in the DN.

In a fourth implementation, the present disclosure provides a method for performing L3 address management function in a session management function (SMF) entity to update an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity, wherein said UPF entity is a core Ethernet switch. The method comprises: receiving, by the UPF entity, a first request message comprising a first request message over layer-2 (L2), said message comprising source media access control of the end user device, from an end user device; forwarding, by the UPF entity, the first request message to the SMF entity; sending, by the SMF entity, a first response message to the UPF entity; forwarding, by the UPF entity, the first response message to the end user device; sending, by the SMF entity, a first request update message to the UPF entity to update the ARP/IPv6 Neighbour cache, wherein the first request update message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map; updating, by the UPF entity, the ARP/IPv6 Neighbour cache with the L2 address map; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In this method, the first request message is a Dynamic Host Configuration Protocol (DHCP) request and the end user device is a user equipment or a client behind a user equipment.

In this implementation, the present disclosure provides an L3 address management function for Ethernet PDU sessions and for the clients behind the UE/DN in the LAN, where the L3 address management function is located at the SMF entity. The L3 address management function may be a DHCP server or an IPv6 SLAAC management function.

Solution 1 for Case 1

FIG. 6 illustrates the call flow sequence for updating the ARP/IPv6 Neighbour cache at the UPF entity when an L3 address is assigned by an SMF entity for case 1. When the SMF entity receives a DHCP request or an IPv6 Router Solicitation, it is received over an L2 Ethernet frame as the UPF entity tunnels the Ethernet PDU it receives as is to the SMF entity. From the L2 frame, the SMF entity identifies the source MAC of the client. After the SMF entity assigns the L3 address to the client by sending a DHCP response/IPv6 Router Advertisement, the SMF entity updates the ARP/IPv6 Neighbour cache in the UPF entity by employing the second implementation of the present disclosure.

In a fifth implementation, the present disclosure provides a method for performing a layer-3 (L3) address management function in a session management function (SMF) entity to update an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity, wherein a data network (DN) is a core Ethernet switch. The method comprises: receiving, by the core Ethernet switch, from the end user device, a first request message comprising a first request message over layer-2 (L2), said message comprising source media access control of the end user device; forwarding, by the core Ethernet switch, the first request message to the SMF entity; sending, by the SMF entity, a first response message to the core Ethernet switch for providing L3 address allocation, wherein the first response message comprises the L3 address allocation forwarded by the SMF; forwarding, by the core Ethernet switch, the first response message to the end user device; acquiring, by the SMF, the L2 addresses for the end user device at the UPF entity as indicated the in the first implementation of the present disclosure; sending, by the SMF entity, a first request update message to the UPF to update the ARP/IPv6 Neighbour cache, wherein the first request update message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map; updating, by the UPF entity, the ARP/IPv6 Neighbour cache with the L2 address map; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In this method, the first request message is a Dynamic Host Configuration Protocol (DHCP) request and the end user device is a user equipment or a client behind a user equipment.

In this implementation, the present disclosure provides a method for updating the ARP/IPv6 Neighbour cache at the UPF entity when an L3 address is assigned by the DN.

Solution 1 for Case 2

When the core Ethernet switch is in the DN, the L3 address allocation request would still reach the SMF entity carrying the source MAC address of the client that sent it. Thus, the solution as described above for case 1 will work for this case as well.

Advantages of the two solutions disclosed hereinabove are that they are completely under 3GPP control, thereby enabling the operators to save their network from paging storm by employing solutions falling within the purview of the 3GPP network's control. Further, these solutions are not computationally intensive and thus, do not unnecessarily hog network resources.

When L3 address management function is at the DN, there are 2 cases to consider.

Case 1:

The UPF entity is the core Ethernet switch.

Case 2:

The core Ethernet switch is in the DN.

In a sixth implementation, the present disclosure provides a method for updating an address resolution protocol (ARP)/IPv6 Neighbour cache in a user plane function (UPF) entity when a layer-3 (L3) address is assigned by a data Network (DN), wherein said UPF entity is a core Ethernet switch. The method comprises: requesting, by a session management function (SMF) entity, for notifying any source layer-2 (L2) address detected by the UPF entity, wherein the L2 address is detected by the UPF entity on a tunnel for a UE at the UPF entity or on a tunnel for clients in the DN; detecting, by the UPF entity, an L2 packet with new source L2 address on said tunnel; sending, by the UPF entity, the new source L2 address detected on said tunnel to the SMF entity; sending, by the DN, a first update message comprising an L2 address and an L3 address map to the SMF entity; forwarding, by the SMF entity, the first update message comprising the L2 address and the L3 address map to the UPF entity to update the ARP/IPv6 Neighbour cache; and sending, by the UPF entity, a first response update message after updating the ARP/IPv6 Neighbour cache to the SMF entity.

In this method, after subscribing for notification on any source L2 address detected on the tunnel by the UPF entity, the method performs the steps of: sending, by an end user device, a first request message comprising a DHCP Request or an IPv6 Router Advertisement to the UPF entity; and forwarding, by the UPF entity, the first request message comprising the DHCP Request or the IPv6 Router Solicitation to the DN.

In this method, after notifying the new source L2 addresses detected on the tunnel to the switch, the method performs the steps of: sending, by the DN, a first response message comprising a DHCP Response or an IPv6 Router Advertisement to the UPF entity; and forwarding, by the UPF entity, the first response message comprising the DHCP Response or the IPv6 Router Advertisement to the end user device.

The end user device is a user equipment or a client behind a user equipment. The tunnel is an N4 setup and tunnel setup at a UPF entity and associated with Ethernet type protocol data unit (PDU) sessions.

In this implementation, the present disclosure provides a method for updating the ARP/IPv6 Neighbour cache at the UPF entity when an L3 address is assigned by the DN.

Solution 2 for Case 1

FIG. 7 illustrates the call flow sequence for updating the ARP/IPv6 Neighbour cache at the UPF entity when an L3 address is assigned by the DN for case 1. Here, for each N4 session, the SMF entity subscribes to the UPF entity to notify it whenever the UPF entity sees a new MAC on the UPF entity tunnel associated with the N4 session. When the UPF entity sees the first L2 packet with a particular source MAC address on a given tunnel (which could be carrying the DHCP Request/IPv6 RS), the UPF entity notifies the SMF entity by employing the first implementation of the present disclosure.

When the L3 address management function in the DN receives a DHCP request or an IPv6 Router Solicitation, it is received over an L2 Ethernet frame as the UPF entity tunnels the Ethernet PDU it receives as is to the DN. From the L2 frame, the DN identifies the source MAC of the client. After the DN assigns the L3 address to the client by sending a DHCP response/IPv6 Router Advertisement, the DN first updates the SMF entity about the <L2 address, L3 address> map by employing the third implementation of the present disclosure. The SMF entity, upon receiving it, updates the ARP/IPv6 Neighbour cache in the UPF entity using the second implementation of the present disclosure.

Solution 2 for Case 2

For case 2 where the core Ethernet switch is in the DN, the L3 address allocation request would still reach the L3 address management function in the DN carrying the source MAC address of the client that sent it. Thus, the solution as described above for case 1 will work for this case as well.

Advantages of the two solutions disclosed hereinabove are that they are completely under 3GPP control, thereby enabling the operators to save their network from paging storm by employing solutions falling within the purview of the 3GPP network's control. Further, these solutions are not computationally intensive and thus, do not unnecessarily hog network resources.

Notably, the two solutions disclosed in the present disclosure do not impact a UE, or impact any other 3GPP Network Functions. Moreover, the UPF entity/core switch in DN need not know the connection management (CM) state of UE. Further, irrespective of which client sends an ARP, the response to the ARP can be sent from the ARP/IPv6 Neighbour cache itself.

It is also possible to perform Deep Packet Inspection (DPI) at a UPF entity. Here, irrespective of where the L3 address management service runs (SMF entity or DN), the MAC address to L3 address mapping is learned by the user plane entities (UPF or Ethernet Switch in DN) through deep packet inspection. DPI at a switch and learning ARP/IPv6 Neighbour cache already exist for wired and wireless LAN Ethernet.

FIG. 8 illustrates deep packet inspection at a UPF entity and building an ARP/IPv6 Neighbour cache when the UPF entity is the core Ethernet switch. When the anchor UPF entity acts as the core Ethernet switch, the anchor UPF entity intercepts the L3 address discovery packets exchanged between UE/clients behind UE/clients in a DN and the L3 address allocation server (e.g. DHCP server) behind the UPF entity. Through that interception, the UPF entity learns which IP address is allocated to which L2 MAC and builds an ARP/I IPv6 Neighbour cache. The packet inspection needed here is minimal as it does not require any stateful inspection or complex layer 7 protocol logic. Subsequently when any client sends an ARP request, the UPF entity itself responds to the ARP. The UPF entity responds to any client that sends ARP on behalf of the entity that owns the IP address sent in ARP request.

FIG. 9 illustrates a core switch in a DN and a UPF entity acting as a tunnelling node to the DN. Here, when the anchor UPF entity tunnels Ethernet packets towards a DNN and the DNN has a core Ethernet switch for the LAN, the UPF entity is just acting as a tunnelling node to an Ethernet switch in a DN behind the UPF entity. The interception of L3 address discovery packets (e.g. DHCP or IPv6 SLAAC) and building of ARP/I IPv6 Neighbour cache can be done in the DN. When the UE sends an ARP request, the UPF entity will tunnel that request to the DN. The DN responds to the ARP request itself by returning the result from the ARP/IPv6 Neighbour cache.

When UPF entity is the core Ethernet switch or when the core switch is in the DN, one may think the ARP/IPv6 Neighbour cache can be built only for UEs and clients behind UEs. However, the UPF entity acting as a case core switch (for case 1) and the DN acting as a core switch (for case 2) may not know deterministically which MAC address belongs to a UE and clients behind the UE and which MAC address belong to clients in the DN.

An advantage of this solution is that it does not require any signalling to 3GPP network elements like the SMF entity, UPF entity, and NEF entity. However, employing packet snooping and deep packet inspection can be computationally intensive. The UPF/Core Ethernet switch in the DN has to do DPI on each packet to snoop which packet carries DHCP/IPv6 SLAAC address assignment. This wastes central processing unit (CPU) cycles at the switch that impacts the forwarding performance. Further, for the case of core Ethernet switch being deployed in the DN, the 3GPP network has to depend on a DPI solution being implemented outside the 3GPP network, which is not at all safe/reliable for the 3GPP network operator. Any solution to avoid the paging storm should be inside the network controlled by the 3GPP operator and not depend on solutions implemented by a 3^(rd) party network switch. Accordingly, performing DPI at a UPF entity may not be worth considering.

In a seventh implementation, the present disclosure provides a method for performing gratuitous address resolution protocol (GARP)/ICMPv6 Neighbour Advertisement to update the Ethernet switch ARP/IPv6 Neighbour cache. The method comprises: initiating, by an application layer, a device trigger message request to initiate GARP/ICMPv6 Neighbour Advertisement for a UE by a network element function (NEF) entity, wherein the device trigger request message comprises an external ID to denote a user equipment (UE); forwarding, by the NEF entity, the device trigger request message to an access management function (AMF) entity if the external ID belongs to a valid UE; forwarding, by the AMF entity, the device trigger request message to an end user device; sending, by the end user device, a device trigger response message to the AMF entity; forwarding, by the AMF entity, the device trigger response message to the NEF entity; and forwarding, by the NEF, the device trigger response message to the application layer.

In this method, if the external ID indicates that the UE is a client behind DN, the device trigger request message is not forwarded to the AMF entity. The end user device is a user equipment or a client behind a user equipment.

In this implementation, the present disclosure provides a method for performing gratuitous address resolution protocol (GARP)/ICMPv6 Neighbour Advertisement to update the Ethernet switch ARP/IPv6 Neighbour cache.

FIG. 10 illustrates the call flow when a core switch performs gratuitous ARP/ICMPv6 Neighbour Advertisement to update the ARP/IPv6 Neighbour cache. In this solution, the UE/client behind UE/clients in a DN, after learning the Layer 3 address, does a gratuitous ARP/ICMPv6 Neighbour Advertisement to update the Ethernet switch (which can be a UPF entity or the DN behind UPF entity) ARP/IPv6 Neighbour cache, where the UE initiates the GARP/ICMPv6 Neighbour Advertisement for itself or on behalf of clients behind it upon receiving a device trigger, and the clients in the DN initiate the GARP/ICMPv6 Neighbour Advertisement based on application triggers that are outside the scope of 3GPP. Through this the switch learns the ARP/IPv6 Neighbour cache. When any client sends an ARP request/ICMPv6 Neighbour Solicitation, the switch itself responds back with the ARP response/ICMPv6 Neighbour Advertisement instead of broadcasting it.

During the IP address allocation procedure, the entity that allocates the IP address (say a DHCP server), based on the client specific parameters, derives an external ID. The external ID is used to initiate a device trigger request towards the NEF. To this end, the application layer (DHCP server or any IP address allocating service) can use the device triggering service defined in TS 23.502.

The NEF, based on authorizing if the external ID belongs to a valid UE or not, will initiate the Device trigger request towards the AMF. If the external ID happens to be that of a client behind DN, then it will not have any valid subscription in the 3GPP network and hence no device trigger will be initiated by the NEF in that case.

In an eighth implementation, the present disclosure provides a network element (100) for acquiring layer-2 (L2) addresses seen in a tunnel for an end user device. The network element, as illustrated in FIG. 11 comprises: a processor unit (101) configured to detect an L2 packet with new source L2 address on said tunnel; a transceiver module (104) configured to receive a request for notifying any source L2 address detected on said tunnel, where said transceiver module is further configured to send the new source L2 address detected on said tunnel; and a memory unit (102) operatively coupled to the processor unit and transceiver module. The tunnel between the network element and a network terminating the end user device is setup by a user plane setup message initiated by a session management function (SMF) entity towards the network element and associated with Ethernet type protocol data unit (PDU) sessions. Additionally, the tunnel setup at the network element is towards an Access Network (AN) or a Data Network (DN).

The memory unit is further configured to update an address resolution protocol (ARP)/IPv6 Neighbour cache with layer-3 (L3) address to L2 address map. The transceiver module is further configured to receive a first request message to update the ARP/IPv6 Neighbour cache and to send a first response update message after updating the ARP/IPv6 Neighbour cache. The first request message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map.

The transceiver module is further configured to: receive a first request message comprising a first request message over L2, said message comprising source media access control of the end user device; send the first request message to the SMF entity; receive a first response message from the SMF entity; send the first response message to the end user device; receive a first request update message to update the ARP/IPv6 Neighbour cache; and send a first response update message after updating the ARP/IPv6 Neighbour cache. Notably, the first request update message comprises an update ARP/IPv6 Neighbour cache message, an L3 address, and an L2 address map. The memory unit is further configured to update the ARP/IPv6 Neighbour cache with the L2 address map. The end user device is a user equipment (UE) or clients behind the UE or clients in DN and the like.

In a ninth implementation, the present disclosure provides a network function entity (200) for updating ab address resolution protocol (ARP)/IPv6 Neighbour cache in a network apparatus by an L3 address management function. The network function entity, as illustrated in FIG. 12, comprises: a processing unit (201) configured to determine a local configuration that indicates which session management function (SMF) is controlling the network apparatus; a transceiver module (203) configured to receive a first update message, wherein said first update message comprises an L2 address and an L3 address map. The transceiver module is further configured to send the first update message to at least one SMF.

The transceiver module is further configured to send the first update message to all the SMF entities in a network, if no local configuration is available or if the network apparatus identifier was not included in the first update message.

The first update message optionally comprises a second identifier of the network apparatus from which the L3 address discovery request was received.

The present disclosure discloses methods for building an ARP/IPv6 Neighbour cache at a UPF entity without performing deep packet inspection on every packet that traverses the network for avoiding paging storm during ARP broadcast for Ethernet type PDU in 5G networks. The principle behind the present disclosure is for the ARP broadcast from any Ethernet client (UE or clients behind UE or clients in DN) to be responded by a UPF entity itself, by looking up the ARP/IPv6 Neighbour cache built in the UPF entity, irrespective of whether the UPF entity acts as the core Ethernet switch or the core Ethernet switch is in the DN. The solution is simplified to always intercept ARP at the UPF entity and respond to it based on a local ARP/IPv6 Neighbour cache.

Notably, the methods of the present disclosure can be used for avoiding ARP broadcast (for IPv4 case) and IPv6 Neighbour Solicitation request multicast (for IPv6 case). The paging issue in ARP broadcast is the same for IPv6 Neighbour Solicitation multicast as well. Thus, there too the response for the Neighbour Solicitation can be returned from the cache built in the UPF entity instead of multicasting it to everyone that is part of the L2 network.

A person skilled in the art may understand that any known or new algorithms may be used for the implementation of the present disclosure. However, it is to be noted that, the present disclosure provides a method that enables implementation of segment routing with traffic engineering to be realized in an existing network without upgrading the product to support higher MSD to achieve the above mentioned benefits and technical advancement irrespective of using any known or new algorithms.

A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular applications and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present disclosure.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present disclosure, or the part contributing to other approaches, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer node (which may be a personal computer, a server, or a network node) to perform all or a part of the steps of the methods described in the embodiments of the present disclosure. The foregoing storage medium includes any medium that can store program code, such as a Universal Serial Bus (USB) flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc.

Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

When a single device or article is described herein, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the disclosure need not include the device itself.

Although implementations for a methods and apparatuses that enables implementing an ARP/IPv6 Neighbour cache at a UPF entity without performing DPI for every packet to be realized for avoiding paging storm during ARP broadcast/Internet Control Message Protocol version 6 (ICMPv6) Neighbour Solicitation multicast for Ethernet type PDU in 5G networks has been described in language related to features and/or methods, it is to be understood that the appended claims are not necessarily limited to the features or methods described. Rather, the features and methods are disclosed as examples of implementations of building an ARP/IPv6 Neighbour cache at a UPF entity. 

What is claims is:
 1. A method of acquiring layer-2 (L2) addresses, comprising: intercepting, by a user plane function entity in a core network, a layer-3 (L3) address discovery packet of a first end user device, wherein the L3 address discovery packet is a Dynamic Host Configuration Protocol (DHCP) packet or an Internet Protocol version 6 (IPv6) stateless address auto-configuration (SLAAC) packet; learning, by the user plane function entity, an L3 address of the first end user device and a layer-2 (L2) address map by performing deep packet inspection (DPI) for the L3 address discovery packet; building, by the user plane function entity, the L3 address and the L2 address map; receiving, by the user plane function entity via a tunnel, a request that carries the L3 address, wherein the request is an address resolution protocol (ARP) request or an Internet Control Message Protocol version 6 (ICMPV6) neighbor solicitation request; and responding, by the user plane function entity, by providing an L2 address corresponding to the L3 address in the request.
 2. The method as in claim 1, wherein the request is the ARP request, and wherein the user plane function entity responds to the ARP request on behalf of an entity that owns the L3 address carried in the ARP request.
 3. The method as in claim 1, wherein the request is the ICMPV6 neighbor solicitation request.
 4. The method as in claim 1, wherein the L3 address is an Internet Protocol (IP) address, and wherein the L2 address is a media access control (MAC) address.
 5. The method as in claim 2, wherein the user plane function entity responds to the ARP request by looking up a local ARP/IPv6 neighbor cache built in the user plane function entity.
 6. The method as in claim 1, further comprising building, by the user plane function entity, a local ARP/IPv6 neighbor cache in the user plane function entity without performing DPI for every packet that traverses the core network, wherein the ARP/IPv6 neighbor cache comprises the L3 address and the L2 address map.
 7. The method as in claim 1, wherein the L3 address discovery packet is a packet between the first end user device and a server, and wherein the first end user device comprises a user equipment (UE) or clients connected to the UE.
 8. A user plane function entity for acquiring layer-2 (L2) addresses, the user plane function entity comprising: a processor configured to: intercept a layer-3 (L3) address discovery packet of a first end user device in a core network in which the user plane function entity is deployed, wherein the L3 address discovery packet is a Dynamic Host Configuration Protocol (DHCP) packet or an Internet Protocol version 6 (IPv6) stateless address auto-configuration (SLAAC) packet; and learn an L3 address of the first end user device and an L2 address map by performing deep packet inspection (DPI) for the L3 address discovery packet; and a transceiver coupled to the processor and configured to: receive, via a tunnel, a request that carries the L3 address, wherein the request is an address resolution protocol (ARP) request or an Internet Control Message Protocol version 6 (ICMPV6) neighbor solicitation request; and respond to the request by providing an L2 address corresponding to the L3 address in the request.
 9. The user plane function entity as in claim 8, wherein the request is the ARP request.
 10. The user plane function entity as in claim 8, wherein the request is the ICMPV6 neighbor solicitation request.
 11. The user plane function entity as in claim 8, wherein the L3 address is an Internet Protocol (IP) address, and wherein the L2 address is a media access control (MAC) address.
 12. The user plane function entity as in claim 8, wherein the L3 address discovery packet is the DHCP packet.
 13. The user plane function entity as in claim 8, wherein the processor is further configured to: build, at the user plane function entity, a local ARP/IPv6 neighbor cache comprising the L3 address and the L2 address map; and respond to the request by using the local ARP/IPv6 neighbor cache to avoid a paging storm when the request is the ARP request or a neighbor discovery request (NDP) issued in the core network, wherein the core network is a 5^(th) generation (5G) network.
 14. The user plane function entity as in claim 8, wherein the L3 address discovery packet is a packet between the first end user device and a server, and wherein the first end user device comprises a user equipment (UE) or clients connected to the UE.
 15. A system of acquiring layer-2 (L2) addresses, wherein the system comprises: a user plane function in a core network, wherein the user plane function is configured to: intercept a layer-3 (L3) address discovery packet of a first end user device, wherein the L3 address discovery packet is a Dynamic Host Configuration Protocol (DHCP) packet or an Internet Protocol version 6 (IPv6) stateless address auto-configuration (SLAAC) packet; learn an L3 address of the first end user device and an L2 address map by performing deep packet inspection (DPI) for the L3 address discovery packet; receive, via a tunnel, a request carrying the L3 address, wherein the request is an address resolution protocol (ARP) request or an Internet Control Message Protocol version 6 (ICMPV6) neighbor solicitation request; and respond to the request by providing an L2 address corresponding to the L3 address in the request.
 16. The system as in claim 15, wherein the request is from a second user end device, and wherein the first end user device and the second end user device are in a same local area network (LAN).
 17. The system as in claim 15, wherein the L3 address is an Internet Protocol (IP) address, and wherein the L2 address is a media access control (MAC) address.
 18. The system as in claim 15, wherein the L3 address discovery packet is the SLAAC packet.
 19. The system as in claim 15, wherein the user plane function is further configured to build a local ARP/IPv6 neighbor cache comprising the L3 address and the L2 address map.
 20. The system as in claim 15, wherein the L3 address discovery packet is a packet between the first end user device and a server, and wherein the first end user device comprises a user equipment (UE) or clients connected to the UE. 